SYSTEM AND METHOD FOR ANONYMOUS OBSERVATION AND USE OF 

PREMIUM CONTENT 
Reference to Related Application 

The present application claims the benefit of U.S. Provisional Application No. 
60/174,377, filed January 4, 2000, whose disclosure is hereby incorporated by 
reference in its entirety into the present disclosure. 
Background of the Invention 

Technical Field 

The present invention pertains in general to computer software, and more 
particularly, to providing the components that give Internet based and other 
technology based providers the ability to charge fees for content, while allowing users 
to maintain their anonymity. 
Description of Related Art 

With the growth of the Internet, and particularly of the World-Wide Web, 
many companies have offered premium content over the Internet. To access such 
premium content, a user must typically enter a credit-card number, both for billing 
purposes and (when required) to establish proof of legal maturity. 

However, companies providing such premium content may wish to allow 
customers a free, time-limited preview of the content. In that case, there must be a 
way of ensuring that the person using the preview does so only during the specified 
time. A generic guest ID and password allow no such function. While the user can be 
prompted to enter a credit card, with the promise that the card will not be charged 
during the preview period, many users are understandably suspicious of such a 
promise. 



Also, a user may wish to remain anonymous during the preview period, or for 
that matter throughout the user's subscription to the premium service. That is 
especially the case with "adult" services. The user's anonymity can be breached in 
several ways. For example, when the user's computer forms a TCP/IP connection to 
5 the server, the user's computer sends certain identifying information to the server, 
which stores that information in an access log. Such information can be used to 
identify the user. Also, if another person (such as a family member or a co-worker) 
accesses the user's computer, that other person can easily identify the URL's of the 
last several Web sites that the user has accessed. Further, in the case of premium 

10 content, a charge will appear on the user's credit-card statements. Many users find 
such recording of their identities objectionable. On the other hand, companies 
providing premium content still have to be able to charge their customers. 
Summary of the Invention 

It will thus be readily apparent that a need exits in the art to overcome the 

15 above problems. It is therefore an object of the invention to allow users to access 
premium content for a limited time. It is another object of the invention to allow 
users to access premium (or other) content on the Web while obscuring their identity 
to both the server and the Web browsers running on such users' computers. 
More specifically, the present invention has the following objects: 

20 1 . To provide Providers with an outlet for selling their Content to anonymous Users. 

2. To provide Providers with the ability to promote their Content by giving free 
access to Content for a limited time. 

3. To provide Users with the ability to purchase Content from a variety of Providers 
while remaining anonymous. 
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4. To provide Users with the ability to access that Content while remaining 
anonymous. 

To provide Portals with the ability to gather information about the Content being 
viewed so Providers can be paid accordingly 

To achieve the objects outlined above, as well as other objects, the present 
invention is directed to a method and system, usable with the World Wide Web and 
other communication technology, for anonymously delivering content to users, while 
giving the providers the ability to charge for the content, as well as for delivering such 
content to users free of charge for a limited time. 

The present invention disclosed and claimed herein, comprises a method and 
system for allowing users to purchase for the right to anonymously view or otherwise 
observe premium content or use premium services available from a variety of 
providers. 

The present invention would typically be implemented through portals, so that 
the users do not access the content directly. The portal provides a variety of providers 
with an outlet to sell content or services (hereafter called content) to an anonymous 
user base. The portal would charge customers (hereafter called users) for the right to 
view the content available from the providers. The portal will maintain the 
information about the content, however, not the specifics on the user who purchased 
it. This permits the users to maintain their anonymity, while allowing the portal to 
charge fees for the content. The fees can be waived during an initial preview period, 
if a provider so desires. 

Viewing as used herein refers to the ability to obverse the content (i.e. look at 
web pages, read text, view still images or motion pictures, listen to audio, etc.). In 
addition, this system can apply to other observations such as tasting, smelling, and 



feeling if and when techniques capable of transmitting this content electronically are 
developed. 

Instead of users purchasing the content directly from the providers - where 
their anonymity would be compromised - users purchase content anonymously 
5 through the portal. The portal serves as an outlet for several providers. When users 
access the portal they are presented with links to content from a variety of providers. 
When users use that content, they are not physically visiting the provider's site, as this 
may compromise their anonymity. Instead, the portal using the method described 
herein retrieves the content, either from the provider's site directly or from a cached 

10 or local copy of the content, and transmits it to the user. In addition, the portal using 
the method described herein could establish a non-traceable link between the user and 
provider for the content to be transmitted. If the content delivered contains links to 
additional content, the system provides for the link to be reformatted before 
displaying the content to the user. As users view the content, their account with the 

15 portal is charged accordingly; however, the specific content that they are viewing is 
not tracked. 

As content is used, the provider's account is credited, again with no tracking 
of information about the specific user using the content. This provides the portal with 
the tracking method and system necessary to pay providers for the content that is 
20 viewed by the portal's users. Portals and providers can charge users using a "charge- 
for-item" method or a "charge-per-time" method. The former method would charge 
users a specified amount for using a specific item of content. The latter method 
would charge users a specified amount per minute for spending time with the content. 
In addition to purchasing content through the portal, users can acquire access 
25 via other means as well. The portal, possibly in conjunction with providers, can setup 
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a number of predefined accounts with a preset limit of time or content usage allowed. 
The user can then purchase these accounts for cash or other means from retailers. The 
retailer would supply the user with the account number, password and time or content 
limit. This information can be supplied via a small card similar to long distance 

5 phone cards currently available. The providers may also use these cards to promote 
their services by giving away cards to prospective customers. 

Users of the service can purchase content credits in two ways. First, by 
establishing an account with the provider and purchasing credits using a credit card 
over the Internet or other medium. Second, by purchasing a pre-paid account for cash 

10 or other means in a form similar to pre-paid phone cards. The second method 
provides even greater anonymity to the user in that the provider, as well as the content 
provider, is unaware of the user's identity. 

The present invention thus allows anonymous observation of premium 
content. A purchaser (user) of premium content connects and logs in to the server 

15 system via the Internet or other electronic medium. The server presents the user with 
a number of options for viewing or otherwise observing premium content (i.e. HTML 
Document, Video or Audio Stream, etc.) from a variety of providers. Through these 
options the user submits a request for an item of content to the server. The server then 
retrieves the content from the content provider's system or from a local cached 

20 version. If the content contains links (i.e. HTML Links) to other items of content at 
the provider, the server changes these links into links that request the same content 
from the server. The content is then delivered to the user's observation device (i.e. 
Web Browser, Telephone, etc.). For content that is live or provided interactively by 
the content provider, the server establishes an anonymously routed connection to the 

25 content provider. If the item fee is based on the amount of time the user spends 
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observing the content, then the server begins a timer. When the user concludes the 
observation of the content the user's account is debited for the amount of the fee. The 
provider's account is credited for the content viewed. The user makes all payments to 
the provider. The provider makes all payments to the providers. There are no direct 
5 payments made from the user to the content provider and no records are maintained of 
the user's content selection, therefore ensuring anonymity. In addition, the user's 
records (i.e. Web Browser History Files, Phone Records, etc.) will only reveal a 
connection to the provider and not the content provider. 
Brief Description of the Drawings 
10 The Description of the Invention and Preferred Implementation makes 

reference to the schematics and models. These include the following: 
Figure 1 —Component Diagram 

This UML Package Diagram shows an overview of the logical design of the 
complete System in the preferred three-tier, component-based architecture. 
15 Figure 2 -Deployment Diagram 

This UML Deployment Diagram shows one of the possible physical 
deployment methods for a complete System. 

Figure 3 —Application Server Component Class Diagram 
This UML Class Diagram shows the association between classes in the 
20 Application Server Component. 

Figure 4 —Database Model 

This Entity Relationship Diagram shows the database table and relationship 
structures for the Database. 
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Figure 5 -Method - Use Case Diagram 

This UML Use Case Diagram shows the primary user interactions with the 
System. 

Figure 6 - Method - Activity Diagram 
5 This UML Activity Diagram shows the Method for retrieving and/or 

connecting anonymous Users to premium Content from Providers 
Figure 7 —Method - Collaboration Diagram 

This UML Collaboration Diagram shows the interaction of Application Server 
objects used to enact the Method for retrieving and/or connecting anonymous Users to 
10 premium Content from Providers. 

Figure 8 -Method - Sequence Diagram 

This UML Sequence Diagram shows the interaction of Application Server 
objects used to enact the Method for retrieving and/or connecting anonymous Users to 
premium Content from Providers, and other related processes. 
15 Detailed Description of the Invention 

The preferred implementation of the system is herein set forth in detail with 
reference to diagrams and schematics. The descriptions reference the diagrams using 
reference numbers as identified in the diagrams and schematics. Reference numbers 
in this section are surrounded by square brackets [ ]. 
20 Logical Component Design and Architecture 

The preferred implementation of the system is that of three-tier, component- 
based architecture as outlined in Figure 1 - Component Diagram. The system is 
organized into three distinct logical layers: the User Layer [110], the Application 
Layer [120], and the Data Layer [130]. 
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Components in the User Layer [110], in response to actions by the User, 
submits requests to components in the Application Layer [120], which in turn 
processes the requests and returns the requested information to the User Layer [110]. 
In processing requests from the User Layer [110], components in the Application 
5 Layer [120] may submit requests to components in the Data Layer [130], which in 
turn processes the request and returns the requested information to the Application 
Layer [120]. In addition to submitting requests to the Data Layer [130], the 
Application Layer [120] may submit requests to Provider Content Servers [134] for 
Content. Content returned by these servers to the Application Layer [120] would then 
1 0 be passed on to the User Layer [110]. 

Components with in a given layer will also collaborate to achieve that layer's 
objective. 

The User Layer 

The User Layer [110] embodies the user interface and presentation logic of the 
15 system. It consists of the following components: User Operating Platform [111], 

Content Viewing Components [1 12], and the User Interface Component [1 13]. 

The User Operating Platform [111] is independent of the system and may 

include a variety of commercially available operating platforms (i.e. Windows 

95/98/NT/2000, Macintosh, UNIX, Linux, set-top boxes, telephones, etc.). Its 
20 purpose is to provide the User with the ability to with access to the Internet or other 

network, and to provide the facilities to run the Content Viewing Components [112]. 

The Content Viewing Components [112] are also independent of the system 

and may include a variety of commercially available content viewing utilities (i.e. 

Microsoft Internet Explorer, Netscape Communicator, Adobe Acrobat, Real Player, 



etc.). Their purpose is to provide the User with ability to access the Portal and use 
available Content. 

The User Interface Component [113] is a component developed and 
maintained by the Portal. It is independent of, but dependent on the Application 
5 Server Component [122]. Its responsibility is to accept input from the User and return 
content and other output to the User's Content Viewing Components [112]. Its 
operations should provide User's with the following features: 

1 . The ability to submit User log-in requests. 

2. The ability to select Content for viewing. 

10 3. The ability to load Content into a Content Viewing Component [1 12]. 
4. The ability to terminate the use of the Content. 

For each User, the User Interface Component [113] should request a unique 
Connection object (described in more detail later) from the Application Server [122]. 
The User Interface Component [113] requests services from the Connection object 
15 that include but are not limited to log-in requests and Content requests. 

Upon receiving results from these requests, it is the User Interface 
Component's [113] responsibility to present the results to the User and provide a way 
for the User to interact with the Content. 

The specific implementation of the User Layer [110] is based on the Content's 
20 format, the User Operating Platform [111], the Content Viewing Components [1 12], 
and the Content Server and Delivery Components [121]. 

The Application Layer 
The Application Layer [120] embodies the business rules and application logic of the 
system. It consists of the following components: Content Server and Delivery 
25 Components [121] and the Application Sever Component [122]. 
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The Content Server and Delivery Components [121] are also independent of 
the system and may include a variety of commercially available web service platforms 
and add-ins (i.e. Microsoft Internet Information Server, Active Server Pages, iPlanet 
Web Server, Cable Broadcast Systems, Telephone Systems, etc.). 

The Application Server Component [122] is a core component of the system 
and is described in greater detail later. 

The Data Layer 

The Data Layer [130] embodies the data storage and retrieval logic of the 
system. It consists of the following components: Data Access Component [131] and 
Relational Database Management System [132], the Database [133] and Content 
Provider Servers [134]. 

The Data Access Component [131] is independent of the system and may be 
implemented using a variety of commercially available components and services (i.e. 
Microsoft DAO, Microsoft ADO, ODBC, JDBC, proprietary database API's, etc.). 
Its purpose is to provide programmers with an Application Programmer's Interface 
(API) for communicating with the Relational Database Management System [132] 
and manipulate data in the Database [133]. 

The Relational Database Management System (RDBMS) [132] is also 
independent of the system and may be implemented using a variety of commercially 
available RDBMS servers (i.e. Oracle, MS-SQL Server, IBM DB/2, etc.). Its purpose 
is to provide a mechanism to store information in the Database [133]. 

The Database [133] is a core component of the system and is described in 
greater detail below. 

The Content Provider Servers [134] are independent of the system. These 
servers are maintained by the Providers of premium Content and can include a variety 



of commercially available products (i.e. web servers, file servers, database server, 
broadcast systems, telephone systems, etc.). 
Physical Deployment Model 

The preferred physical deployment model for the System is that of distributed 
5 system. Figure 2 - Deployment Diagram outlines a typical implementation of that 
model. 

The system can be deployed on up to 4 or more nodes (computers or other 
physical devices): User Device [210], Web Server [220], Application Server [230], 
and Database Server [240]. These devices are then connected using currently 
10 available network technology. 

User Device Node 

The users of a Portal maintain the User Device Node [210]. Components installed on 
this machine include the User Operating System [211], and the Content Viewing 
Components [212]. User devices may include but are not limited, personnel 
15 computers, televisions and set-top boxes, or telephones. 
Content Server Node 

The Portal maintains the Content Server Node [220]. Components installed on this 
machine include the Content Service Components [221] and the User Interface 
Component [222]. Content Servers may include but are not limited to web servers, 
20 database servers, file servers, electronic libraries or electronic broadcasting system. 
Application Server Node 
The Application Server [230] is maintained by the Portal. Components installed on 
this machine include the Application Server Component [231] and the Data Access 
Component [232]. 
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Database Server Node 
The Portal maintains the Database Server [240]. Components installed on this 
machine include the Relational Database Management System [241] and the Database 
[242]. 

Content Provider Server Nodes 

The various Content Providers maintain the Content Provider Server Nodes 
[250]. These nodes may include a variety of server types and components including 
but not limited to web servers, file servers, database server, broadcast systems and 
telephone systems. 

Alternative Deployment Methods 

In addition to the deployment method outlined here and in Figure 2, 
alternative deployment methods can be used. Alternative deployment methods may 
be selected based on factors such as the number of simultaneous users and the 
available technology for the given Content format. 

In one alternative method, all components installed on the Content [221, 222], 
Application [231, 232], and Data [241, 242] Servers Nodes, as outlined above, can be 
installed instead on a single server machine, eliminating the need for two of the three 
machines maintained by the Portal. 

In a second alternative, components installed on the Application Server Node 
[231, 232], as outlined above, can be installed instead with components on the Web 
Server Node [220], eliminating the need for a separate Application Server Node 
[230]. 

In a third alternative, components installed on the Application Server Node 
[231, 232], as outlined above, can be installed instead with the components on the 
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Database Server Node [241, 242], eliminating the need for a separate Application 
Server Node [230]. 

In a fourth alternative, multiple instances of the Content [220] and Application 
[230] Server Nodes can be deployed to handle requests from large numbers of Users. 
The Application Server Component 

The preferred implementation is that of an object-oriented component as 
outlined in Figure 3 - Application Server Component Class Diagram. 
Component Overview 

The Application Server Component embodies the business rules and 
application logic of the System. This components has the following objectives: 

1 . Maintain the state of the data associated with systems entities. 

2. Interact with Database for object and data persistence. 

3. Maintain and enforce data integrity and security. 

4. Maintain an accounting of User and Provider credit balances. 

5. Retrieve, process and maintain cached versions of Provider Content. 

6. Process Provider Content as follows: Convert links to additional Content into 
Content requests to the Application Server Component. This serves the purpose of 
keeping the User inside of the Portal, preventing them from viewing content directly 
from the Provider's Server, therefore maintaining anonymity. 

To accomplish these objectives the preferred implementation organizes the 
component into the following class modules: Connection [310], User [320], 
UserCredit [330], UserDebit [340], Provider [350], ProviderContent [360], and 
ProviderCredit [370]. 
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This component can be implemented using a variety of currently available 
object-oriented programming languages and technologies (i.e. C++, Visual Basic, 
COM, DCOM, Java, JavaBeans, CORBA, etc.). 

The Connection Class 

The Connection Class [310] represents the root class of the Application Server 
Component. It provides the following operations: 

1. Maintains the state Connection objects. 

2. Creates, retrieves and maintains User [320], UserCredit [330], UserDebit [340], 
Provider [350], and ProviderCredit [370] objects. 

3. Retrieve Content from Content Service Provider Nodes [250] 

4. Verifies User log in requests. 

5. Maintains a connection to the Database [133] using the Data Access Component. 

The User Interface Component [114] will establish a reference to this object 
when Users connect to the Portal. 
The User Class 

The User Class [320] represents a User Account of the System. An Instance 
(or object) of this class exists for each user that is logged in to the system. It provides 
the following functionality: 

1 . Maintains the state of User objects. 

2. Maintains User object persistence in the User Table [520] using the Data Access 
Component. 

3. Creates, retrieves and maintains UserCredit [330] and UserDebit [340] objects. 

4. Maintains accounting of the User's Credits and Charges. 

5. Verifies User passwords. 



The UserCredit Class 

The UserCredit Class [330] represents a User's purchase of Credits. It is used 
by user interface components, provided by the portal, that allow the User to purchase 
Content rights. It provides the following functionality: 

1 . Maintains the state of UserCredit obj ects. 

2. Maintains UserCredit object persistence in the UserCredit Table [530] using the 
Data Access Component. 

In addition, this class can maintain information on the specific Provider or 
Provider Content for which the credit can be used. 
The UserDebit Class 

The UserDebit Class [340] represents a charge for a User viewing Pay-per- 
view Content. Instances of this class exist when posting debits to the User's account. 
It provides the following functionality: 

1 . Maintains the state of UserDebit obj ects. 

2. Maintains UserDebit object persistence in the UserDebit Table [540]. 

In addition, this class can maintain information on the specific Provider or 
Provider Content for which the User account was charged. 
The Provider Class 

The Provider Class [350] represents a Content Provider. Instances of this 
class exist when a User is using the Content from the Provider. It provides the 
following functionality: 

1 . Maintains the state of Provider objects. 

2. Maintains Provider object persistence in the Provider Table [550] using the Data 
Access Component [131, 232]. 
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3. Creates, retrieves and maintains ProviderContent [360] and ProviderCredit [370] 
objects. 

4. Maintains accounting of the Providers Credits and Content Usage. 

5. Retrieves, processes and returns the Content information. 

6. Optionally maintains a cached version of the Content close to the Portal's 
Application Server. 

The ProviderContent Class 
The ProviderContent Class [360] represents a specific item of Pay-per-view Content. 
Instances of this class exist when a User is using the Content it represents. It provides 
the following functionality: 

1 . Maintains the state of ProviderContent objects. 

2. Maintains ProviderContent object persistence in the ProviderContent Table [560] 
using the Data Access Components. 

3. Creates, retrieves and maintains ProviderCredit [370] objects. 

4. Retrieves, processes and returns the Content from Provider. 

5. Optionally maintains a cached version of the Content closer to the Portal's 
Application Server 

The ProviderCredit Class 

The ProviderCredit Class [370] represents a credit for Provider Content that is 
being viewed. Instances of this class exist when posting a credit to the Provider's 
account. It provides the following functionality: 

1 . Maintains the state of ProviderCredit objects. 

2. Maintains ProviderCredit object persistence in the ProviderCredit Table [570] 
using the Data Access Components. 

3. Maintains accounting of fees earned during the session. 
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The Database 

The preferred implementation is that of a relational database as outlined in 
Figure 4 -Database Model. 
Database Overview 

The Database defines the structure for information stored and maintained by the 
System. This database has the following objectives: 

1 . Persistently maintain the state of the obj ects and other data of the system. 

2. Provide procedures for saving, retrieving and deleting data. 

To accomplish these objectives the preferred implementation organizes the 
database into the following table definitions: User [420], UserCreditPurchase [430], 
UserSession [440], Provider [450], ProviderContent [460], and ProviderCredit [470]. 

The User Table 

The User Table [420] is used to persist the state of User objects. It provides 
data fields for storing the User Id (a primary key that uniquely identifies each User), 
log in, User's credit balance, and other information. 

The UserCreditTable 

The UserCredit Table [430] is used to persist the state of UserCredit objects. 
It provides data fields for storing the User Id (a foreign key identifying the User 
credited), and the date and amount credited. 

The UserDebit Table 

The UserDebit Table [440] is used to persist the state of UserDebit objects. It 
provides data fields for storing the User Id (a foreign key identifying the User), the 
time the User entered and exited the Content, and the amount of debited to their 
account. 
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The Provider Table 

The Provider Table [450] is used to persist the state of Provider objects. It 
provides data fields for storing the Provider Id (a primary key that uniquely identifies 
each Provider), name, address information, content location, and Content pricing 
information. 

The ProviderContent Table 

The ProviderContent Table [460] is used to persist the state of 
ProviderContent objects. It provides data fields for the Provider Content Id (a 
primary key that uniquely identifies each item of Provider Content), the Provider Id (a 
foreign key identifying the Provider), content location and pricing information. This 
table may also provide data elements for storing cached or local copies of the Content. 

The ProviderCredit Table 

The ProviderCredit Table [470] is used to persist the state of ProviderCredit 
object. It provides data fields for the Provider Id (a foreign key identifying the 
Provider), the Provider Content Id (a foreign key identifying a specific item of 
Provider Content (optional)), the time the Content was entered and exited, content 
location, and the amount of credited to the Provider account. 

The Method 

The process and preferred implementation of the Method is outlined in Figure 
5 - Method - Use Case Diagram, Figure 6 - Activity Diagram, Figure 7 - 
Collaboration Diagram, and Figure 8 - Sequence Diagram. 

The Process 

The Process is the sequence of events used for delivering Pay-per-view 
Content to Anonymous Users. Figure 5, a UML Activity Diagram, shows an 



overview of this process. The numbered items in the diagram represent the activities 
that take place during the process. Descriptions of these activities follow. 

601. The User, via the User Device submits a request to the portal for an item or area 
of Content. 

602. The System retrieves information about the content from the Database. 

603. If the Content is of the type that can be delivered, the System will retrieve the 
actual Content from either the Content Provider Servers or from a local copy of 
cached version of the Content. This may be stored in the Database or other local 
storage system. 

604. The Content is examined for the presence of direct links or requests to the 
Content Provider. 

605. If the Content does contain such links, the links are reformatted or replaced by 
request links to the System. This will prevent the User from directly linking to the 
Content Provider, which nullify their anonymity. 

606. The Content is delivered to the User Device via currently available technologies 
(i.e. web servers, database servers, telephone systems, cable systems, etc.). 

607. Referring to Activity 602, If the Content is of the type that can not be delivered 
to the User anonymously and a connection to the Content Provider Nodes, then the 
system will establish a link to said Node acting as a proxy for the User. 

608. The system will establish a link to the User Device acting as a proxy for the 
Server. Content from the Provider will then be routed via these connections. The 
specific connections and routing technologies to be used are independent of the 
system and can be implemented using a variety of commercially available products. 
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609. When the User Interface Component notifies the System that User has completed 
observing the Content, any anonymously routed connections established between the 
User and Content Provider are Terminated. 

610. A Credit for the observation of the Content is posted to the Provider's account. 
5 61 1 . A Debit for the observation of the Content is posted to the User's account. 

User Interactions 

For the viewing Pay-per-view Content anonymously, the User will have two 
primary interactions with the system: requesting Content from the Portal and 
completing the viewing of that content. Figure 6, a UML Use Case Diagram shows 
10 the various interactions between the User and the System process. 

The User may request content [510] through a wide variety of currently 
available technologies. These include but are not limited to the following: 

1 . Selecting content or provider link from the web site of the Portal. 

2. Entering a content or provider identifier via a computer based data entry system. 
15 3. Entering a content or provider identified via a prompt driven phone system. 

4. Selecting a channel or other option via a set-top box or television. 

The User Content request [510] will be honored by the system, either by 
retrieving [511] and possibly reformatting [512] the Content or by establishing an 
anonymously routed connection between the User Device and the Content Server 
20 [513]. 

The User may complete the observation of content [520] in a wide variety of 
ways that depend primarily on the implementation technology. These methods of 
completing the observation include but are not limited to the following: 
1 . Selecting a link to a different provider, or a different item or area of content via 
25 the user interface provided. 
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2. Selecting an option to logout of the system. 

3 . Closing or exiting the web browser or other viewing component. 

4. Disconnecting of turning off the User Device. 

5. Changing the channel on of turning of a set-top box or television. 
5 6. Hanging up the phone. 

When the User has notified the Portal, through one of the above or other 
means, that the Content observation is complete [520], the System will system will 
account for the session by posting a credit to the Provider's account [521] and a debit 
to the User's account [522]. To preserve User anonymity, no connection or links 
10 between these posting are maintained. 

Component Object Interactions 

The preferred implementation of the Method is an object-oriented software 
component as described earlier (Application Server Component). To achieve the 
objectives of the Method, objects (or class instances) in the Application Server 

15 Component collaborate with each other, each performing a particular task. Each 
object sends messages to others by calling the methods (or functions) that are 
provided by the other objects. Figure 7, a UML Collaboration Diagram, shows the 
inter-object message scheme for the Application Server Component. Ordered 
descriptions of these messages follow: 

20 701. An object from the User Interface Component [7000] sends a Log-In request to 
the Connection object [7100]. 

702. The Connection object [7100] sends a Log-in message to the User object [7200], 

703. An object from the User Interface Component [7000] sends a Content request to 
the Connection object [7100]. 
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704. The Connection object [7100] sends a Retrieve Content Information message to 
the Provider object [7500]. 

705. The Provider object [7500] sends a Retrieve Information message to the 
ProviderContent object [7600]. 

706. (a) If the Content can be delivered, the Connection object [7100] sends a 
Retrieve Content message to the ProviderContent object [7600]. (b) If the Content 
requires a connection, the Content object [7100] sends a Provide Connection message 
to the ProviderContent object [7600]. 

707. If the Content contains direct links or requests to the Provider, the 
ProviderContent [7600] sends a Reformat message to itself. 

708. An object from the User Interface Component [7000] sends an Observation 
Complete message to the Connection object [7100]. 

709. The Connection object [7100] sends a Terminate Connection message to the 
ProviderContent object [7600]. 

710. The Connection object [7100] sends a Post message to the ProviderCredit object 
[7700]. 

711. The Connection object [7100] sends a Post message to the UserDebit object 
[7400]. 

In addition to sending messages to other objects, some objects are responsible 
for the creation and deletion of objects. The Connection object is created by the User 
Interface Component a User connects to the System, and continues to exist until the 
user disconnects. Many other objects in the Application Server only need to exist for 
short periods of time. Figure 8, a UML Sequence Diagram, shows the lifetime of 
such objects as various messages are processed by the Connection object [810]. 
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Upon receiving a log-in request [801] from the User Interface Component, the 
Connection object [810] creates a new instance [801.1] of a User object [820]. The 
Connection object [810] then sends the Login message [801.2] to the User object 
[820]. The User object continues to exist until the User disconnects and the 
5 Connection object is deleted. 

Upon receiving a content request [802] from the User Interface Component, 
the Connection object [810] creates anew instance [802.1] of a Provider Object [850]. 
The Connection object [810] then sends a Retrieve Content Request message [802.2] 
to the Provider object [850]. In response to this message, the Provider object [850] 
10 creates a new instance [802.3] of a ProviderContent object [860] and sends it the 
Retrieve Information message [802.4]. Both the Provider object [850] and the 
ProviderContent object [860] continue to exist until the User disconnects. After the 
Connection object [810] examines the Content information, it either sends the 
Retrieve Content or the Provide Connection message [802.5] to the ProviderContent 
15 object [860]. In response to the Retrieve Content message, the ProviderContent 
retrieves the Content and if necessary sends a Reformat message [802.6] to itself. 

Upon receiving an observation complete message [803] from the User 
Interface Component, the Connection object [810], if a connection to the Content was 
provided, sends the Terminate Connection message [803.1] to the ProviderContent 
20 object [860]. It then creates a new instance [803.2] of a ProviderCredit [870], sends 
that object the Post message [803.3], and then deletes [803.4] the ProviderCredit 
object [870]. It then creates a new instance [803.5] of a UserDebit [840], sends that 
object the Post message [803.6], and then deletes [803.7] the UserDebit object [840]. 
The Connection object [810] then deletes [803.8] the Provider object [850]. This 
25 deletion cascades a deletion [803.9] to the ProviderContent object [860]. 
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Upon receiving a user disconnect message [804] from the User Interface 
Component, the Connection object [810] deletes [804.1] the User object [820]. 
NOTE - If the user is observing content when the user disconnect message [804] is 
received, the Connection object [810] will send an Observation Complete message 
[803] to itself. 

Resources Required for Implementation 

Content Delivery and Viewing Platforms 

As the design set forth herein is independent of any specific computing or 
other content delivery and viewing platform, the design can be applied to a wide 
variety of such platforms. Two distinct platforms are required: a content server and 
delivery platform and a user platform. 

The types of content server and delivery platforms the design herein could be 
applied to include but are not limited to the following: 

1. Windows based computers (i.e. Pentium computers running Windows operating 
system, web server, and data server software). 

2. UNIX based computers (i.e. Sparc workstation running UNIX operating system, 
web server, and data server software). 

3. Other server capable computers (i.e. Linux systems, Mainframes computers, etc.). 

4. Broadcast, cable and satellite based television and radio systems. 

5. Telephone systems. 

6. Voice response, recognition and generation systems. 

The types of user platforms the design herein could be applied to include but 
are not limited to the following: 

1 . Personal Computer systems (i.e. Windows, Macintosh, UNIX, Linux, etc.). 
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2. Internet access software (i.e. Microsoft Internet Explorer, Netscape Navigator, 
etc.). 

3. Internet access devices (i.e. Internet terminals, television set-top boxes, etc.). 

4. Computer based game systems. 

5. Cable and satellite television and radio receivers. 

6. Hand held and wearable computer devices. 

7. Telephones 

Development Tools 

As the design set forth herein is independent of the specific implementation 
techniques, a wide variety of commercially available tools could be used to develop 
the components described. The types of tools that may be required include but are not 
limited to: 

1 . Object Oriented Programming tools (i.e. Visual C++, Visual Basic, Visual Age for 
Java, etc.) 

2. Distributed Component Deployment tools (i.e. DCOM, CORBA, etc.) 

3. Relational Database System (i.e. Oracle, MS SQL Server, IBM DB/2, etc.) 

4. Web Component Development tools (i.e. Java, CGI, Perl, Visual Basic, Active 
Server Pages, etc.) 

5. Browser and Other Component markup and scripting tools (i.e. JavaScript, 
VBScript, HTML, DHTML, etc.). 

6. Broadcast, cable and satellite systems. 

7. Telephone systems. 
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Programming and Other Talent 

The programming talent required to build the preferred implementation is 
dependent primarily on the target operating platform of the system. Typical skill set 
may include the following: 
5 1. Object-oriented programming language skills. 

2. Component-based and multi-tier, client-server development skills. 

3 . Relation database programming skills. 

4. Thin-client and web programming skills. 

5. HTML and other presentation design skills. 

10 6. Web Server and Database Server implementation and administration skills. 

7. Broadcast, Cable and Satellite system programming skills. 

8. Telephone system programming skills. 

The design set forth herein is sufficient as to not require a programmer to 
create any new invention to implement the system. The techniques required to 
15 implement the various designs of the method and system are based on currently 
available and commonly known technologies, programming techniques and 
algorithms. 

While a preferred embodiment and various alternatives have been set forth 
above, those skilled in the art will readily appreciate that other embodiments are 

20 possible within the scope of the invention. For example, communication networks 
other than the Internet, such as the public switched telephone network and proprietary 
data networks, can be used. Also, any hardware capable of use with such networks 
can be used. Furthermore, while the portal has been disclosed as usable with multiple 
providers, it can be used with only one provider. Moreover, different networks could 

25 be used to connect the system to the user and to the providers; for example, the user 
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could dial up to the system, which would then function as an ISP in connecting the 
user to the providers. Therefore, the present invention should be construed as limited 
only by the appended claims. 
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